Status:  U
Date: Wed, 25 May 2011 17:04:14 -0600
From: Willard Goosey <goosey@virgo.sdc.org>
To: CoCoList for Color Computer Enthusiasts <coco@maltedmedia.com>
Message-ID: <20110525230414.GA14913@brawl.fslf.org>
References: <20110524212513.GA6439@brawl.fslf.org>
	<201105250032.09184.gheskett@wdtv.com>
	<A7EEA425FE814B7CA062FA0D5F10BCFD@Shasta>
	<20110525195346.GC14480@brawl.fslf.org>
	<9B6B5EC6-BC3F-4088-B92E-7A47ABA349BA@ocs.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9B6B5EC6-BC3F-4088-B92E-7A47ABA349BA@ocs.net>
User-Agent: Mutt/1.4.1i
Subject: Re: [Coco] cprep19 __FILE__ fix?
Precedence: list
Reply-To: CoCoList for Color Computer Enthusiasts <coco@maltedmedia.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: coco-bounces@maltedmedia.com
Errors-To: coco-bounces@maltedmedia.com

On Wed, May 25, 2011 at 02:49:23PM -0700, Michael Furman wrote:

> Willard, I looked into this a few months ago.  Off the top of my haead:
> 
> 1) I have some source for the Krieder C library, but when I
> 1) assembled it, it was not exactly the same as binary copies
> 1) floating around.  This reduces my confidence that the resulting
> 1) clib after hacking will actually work properly, and makes it
> 1) difficult to generate a patch that will always work.  The date
> 1) command returns the correct year.

Bleah.  I'm still trying to debug curses, I'm not about to start
messing around with clib.

> 3) I took a look at Nitros9's date command and it has some Y2Kish
> 3) stuff there but it's not clear if it works correctly.  The
> 3) algorithm there seemed a bit convoluted or worked the problem
> 3) backwards (from my perspective) for some unknown reason (to
> 3) optimize it? for 8-bit math apparently?).  The comment in
> 3) date.asm is from Grandpa Gene:
> *   5      1996/09/25  Gene Heskett
> * Made Y2K compliant.

I believe there was some trouble about making sure <2000 dates in file
timestamps and things like that didn't break, but I don't really
remember the discussion, I just used the results.

Gene?  Any comments?
> 
> 4) It appears that Nitros9 keeps a 1-byte year, so this is what one
> 4) would expect F$Time to return.  According to OS9Defs:
> D.Time         equ       .                   System Time
> D.Year         rmb       1

Heh, gonna be trouble in 2157, or maybe even 2028 if something tries
to look at that as a signed number.
> 
> I'll try to fill in the rest of details from my previous
> investigation of this issue later this evening.

Good luck!
> 
> The result was that to fix UUCPBB (Which reported the year as 19111
> in some places and 111 in others) I basically changed any occurrence
> of '19%d', year to '%d', 1900+year.  This was a hack that doesn't
> address the real lower level problem.

Heh, yup.  That's the plan for cprep19. ;-)  Since the date string is
of fixed length, I know which characters to overwrite.

Willard
-- 
Willard Goosey  goosey@sdc.org
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  -- R.E. Howard

--
Coco mailing list
Coco@maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco